Telecommunications services provided over an IP Connectivity Access Network (IP-CAN) can be subject to charging and policy control mechanisms. This includes service-aware Quality of Service (QoS) control. Accordingly, some telecommunications systems incorporate Policy and Charging Control (PCC) architectures to provide this control. 3GPP TS 23.203 describes such a PCC architecture in respect of packet flows in an IP-CAN session established by a user terminal through an Evolved 3GPP telecommunications system, including both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses. FIG. 1 illustrates schematically an example of the PCC architecture described in 3GPP TS 23.203 that comprises a Policy and Charging Enforcement Function (PCEF), a Policy and Charging Rules Function (PCRF), an Application Function (AF), an Online Charging System (OCS), an Offline Charging System (OFCS) and a Subscription Profile Repository (SPR). The architecture can also include a Bearer Binding and Event Reporting Function (BBERF).
The PCRF is a functional element that encompasses policy control decision and flow based charging control functionalities, a combination of the functionality of the Policy Decision Function (PDF) and the Charging Rule Function (CRF) defined in release 6 of the 3GPP specification. A PCRF can be implemented as a standalone node and behaves as a Policy Decision Point (PDP), or Policy Server (PS), that stores user data related to QoS enforcement, access control lists, etc. The PCRF provides policy and charging control for the media components negotiated between the user terminal and the AF. The PCRF receives session and media related information from the AF and informs the AF of traffic plane events. The PCRF also provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF. The PCRF can provision PCC rules and PCC decisions to the PCEF via a so-called Gx reference point and to the BBERF through a so-called Gxa/Gxc (also referred to as Gxx) reference point. The PCRF also forwards events between the BBERF, the PCEF, and the AF. Criteria such as the QoS subscription information may be used together with policy rules such as service-based, subscription-based, or pre-defined PCRF internal policies to derive the authorized QoS to be enforced for a service data flow. The PCRF PCC decisions may be based on one or more of the following:                information obtained from the AF via a so-called Rx reference point, e.g. the session, media and subscriber related information;        information obtained from the PCEF via the Gx reference point, e.g. IP-CAN bearer attributes, request type, subscriber related information and location information;        information obtained from the SPR via a so-called Sp reference point, e.g. subscriber and service related data;        information pre-defined in the PCRF; and        information obtained from BBERF via the Gxa/Gxc (also referred to as Gxx) reference points.        
The PCEF is a functional entity that behaves as a Policy Enforcing Point (PEP) for enforcing decisions instructed by the PCRF and the OCS. The PCEF provides service data flow detection (based on service data flow filters defined in the PCC rules) to capture and analyse any user and signalling traffic, to identify the user and to capture details of the service(s) being used. The PCEF can then communicate this user and access-specific information to the PCRF over the Gx interface, to the OCS over a so-called Gy interface and to the OFCS over a so-called Gz interface. The PCEF enforces QoS control according to the QoS authorised by the PCRF. The PCEF is preferably co-located within a gateway node implementing the IP access to a Packet Data Network (PDN GW). As such, in a General Packet Radio Service (GPRS) core network the PCEF is located within a GPRS Gateway Support Node (GGSN), whilst in the case of a CDMA2000 network the PCEF may be located in a Packet Data Serving Node (PDSN), and in a WLAN network the PCEF may be located in a Packet Data Gateway (PDG).
The BBERF supports a subset of the functions provided by the PCEF that includes bearer binding, uplink bearer binding verification and event reporting to the PCRF.
Bearer binding is the association of a PCC rule and a QoS rule (if applicable) to an IP-CAN bearer within that IP-CAN session, and is performed by the Bearer Binding Function (BBF). The BBF is located at the PCEF if GPRS Tunnelling Protocol (GTP) is used as the mobility protocol towards the PCEF. Otherwise, where a mobile-IP based protocol, such as Mobile IP (MIP), is used instead of GTP, the BBF is located at the BBERF. The QoS rules contain the information from the PCC rules that the BBERF requires to ensure that bearer binding can be performed. The QoS rules therefore contain the SDF template and precedence information, as well as the QoS information (e.g. QCI, bit rates etc). The PCRF provides the BBERF with the QoS rules derived from the PCC rules. The BBERF then enforces the QoS decisions by setting up the appropriate bearers. The Gxx reference point represents the Gxa or Gxc reference points as applicable in each particular context. Gxc applies when the BBERF is located in the S-GW of a 3GPP access, whereas Gxa applies when the BBERF is located in a trusted non-3GPP access.
The AF is an element offering applications that require policy and/or charging control of the IP-CAN user plane behaviour. The AF communicates with the PCRF over the Rx interface to transfer dynamic session information (e.g. a description of the media to be delivered in the transport layer) required for PCRF decisions, as well as to receive IP-CAN specific information and notifications about IP-CAN bearer level events. One example of an AF is the Proxy Call/Session Control Function (P-CSCF) of the IP Multimedia Subsystem (IMS). In the case of a P-CSCF, the information communicated over the Rx interface is derived from the P-CSCF session information and it mainly includes media components. A media component comprises a set of IP flows, each of which is described by a 5-tuple, the media type and required bandwidth. The AF can also subscribe to certain events that occur at the traffic plane level (i.e., events detected by either the PCEF or be BBERF). Those traffic plane events include events such as IP session termination or access technology-type change. When the AF has subscribed to a traffic plane event, the PCRF informs the AF of its occurrence.
The SPR contains all subscriber/subscription related information needed for subscription-based policies and IP-CAN bearer level PCC rules by the PCRF. The Sp interface allows the PCRF to request subscription information related to the IP-CAN policies from the SPR based on a subscriber ID and other IP-CAN session attributes.
For a UE attached to an IP-CAN, there may be various circumstances in which it is required that the IP address allocated to the UE must change whilst the UE is receiving a service provided through the IP-CAN. A typical example of such a scenario is when a UE is connected to a core network via a first IP-CAN and either the core network or the UE determines that the UE should change to an alternative second IP-CAN and, in particular, where the first IP-CAN and second IP-CAN implement heterogeneous access network technologies (i.e. are 3GPP and non-3GPP access networks). In this regard, both IPv4 and IPv6 address consist of a network prefix and a host/interface identifier. Therefore, when the UE moves from the first IP-CAN to the alternative second IP-CAN, the network prefix of the second IP-CAN will be different to that of the first IP-CAN, such that the IP address of the UE must change.
A change in the IP address allocated to a UE will result in an interruption of any existing streams of IP packets (i.e. IP flows) sent to and from the UE, and this will cause an interruption in any services that are currently being accessed by/provided to the user of the UE. In this regard, whilst an interruption of the service might not be considered a severe problem when the user is browsing the web (i.e. due to the bursty nature of web browsing), an interruption in a streaming service such as IPTV, video downloading, application downloading, etc, might be considered a severe disruption by the user.
The current solutions for mitigating against the problem of service interruption due to a change in the IP address of a UE are implemented in either the IP protocol stack or the application layer. Solutions that are implemented in the IP protocol stack make use of a shim layer that takes care and minimizes the effect of changing the IP address of the device. Examples of these solutions include Mobile IPv4, Mobile IPv6, Proxy Mobile IPv6, and Host Identity Protocol (HIP). However, these solutions that require a change the IP protocol stack are complex in nature, requiring significant changes in devices, programming Application Program Interfaces (APIs), infrastructure, configuration, etc. As a result, the trend is to provide application layer solutions in which those applications that are impacted upon by a change in the IP address attempt to minimize the perceived service interruption. However, these application layer solutions therefore require that each individual application that could be affected by such a change is updated so as to implement such a solution.